Datenobjekt Contact

Inhalt des Datenobjekts

Das Datenobjekt "Contact" enthält die relevanten Daten zu Kontakten des Typs

 

PERSON und ORG

mit den Kontaktdaten:

  • eindeutiges Handle,

  • Domaininhabern,

  • Adresse,

  • E-Mail,

  • Telefonnummer,

  • Verifikationsinformationen,

 

REQUEST

mit den Kontaktdaten (für General Request oder Abuse Contact):

  • eindeutiges Handle,

  • URI-Template.

 

Bearbeitungsmöglichkeiten

Mit Hilfe der Auftragsformen Contact CREATE und Contact UPDATE können Sie einen neuen Contact anlegen, oder einen bereits vorhandenen ändern.

 

Aufbau und Regeln für Contacts der Typen PERSON und ORG

K/V-Schlüsselwort XML-Namensraum und Element Vorkommen
min - max 		Typ / Länge Wertebereich Beschreibung Policy
Handle contact:handle 1 token 9 - 32 contact-rule Eindeutige ID des Contacts,
Syntax: <RegAccId>-<ID vom Mitglied> 		Das Handle eines Contacts muss immer mit der eigenen RegAccId des verwaltenden RegAccs beginnen.
Type contact:type 1 enumeration role-erule Typ des Contacts:
  • PERSON = natürliche Person,
  • ORG = eine juristische Person (Firma, Verein, Inhabergemeinschaft, Organisation etc.
  • Der Typ des Contacts kann nachträglich geändert werden.
  • Für Holder ist der Typ PERSON oder ORG.
Name contact:name 1 normalizedString 1 - 255 name-rule Name des Contacts Der Name kann nach dem Anlegen nicht mehr geändert werden
Organisation contact:organisation 0 - * normalizedString 1 - 255 organisation-rule Organisation, für die der Contact tätig ist
  • nur erlaubt bei Type PERSON
  • nicht änderbar, sofern die Domain mit einem DISPUTE belegt ist.
  • Der Domaininhaber muss immer im Feld „Name:“ angegeben werden. Der Wert von „Organisation“ hat keine Rechte an der Domain und kann zum Beispiel auch keine AuthInfo bzw. keinen Providerwechsel beantragen.
Address contact:address 1 - * normalizedString 1 - 255 address-rule Straße und die Hausnummer des Contacts Nicht änderbar, sofern der Contact als Holder von einer Domain referenziert wird, die mit einem DISPUTE belegt ist.
PostalCode contact:postalCode 1 token 1 - 20 postalcode-rule Postleitzahl der Anschrift des Contacts Nicht änderbar, sofern der Contact als Holder von einer Domain referenziert wird, die mit einem DISPUTE belegt ist.
City contact:city 1 normalizedString 1 - 80 city-rule Wohnort des Contacts Nicht änderbar, sofern der Contact als Holder von einer Domain referenziert wird, die mit einem DISPUTE belegt ist.
CountryCode contact:countryCode 1 Enumeration
2 		country-erule Countrycode des Landes, in dem der Wohnort des Contacts liegt.
  • Erlaubt sind nur Countrycodes aus der ISO-3166-1 alpha-2 Liste
  • Nicht änderbar, sofern der Contact als Holder von einer Domain referenziert wird, die mit einem DISPUTE belegt ist.
Email contact:email 1 - * normalizedString 3 - 255 email-rule

(siehe RFC5322 - Internet Message Format) 		E-Mail-Adresse des Contacts „email“ ist ein Pflichtfeld und muss bei Contact CREATE- und Contact UPDATE-Aufträgen für die Typen PERSON und ORG mindestens einmal angegeben werden.

 

Aufbau und Regeln für den Verifikationsinformationsblock bei Contacts der Typen PERSON und ORG

K/V-Schlüsselwort XML-Namensraum und Elemente 1. Verschachtelung 2. Verschachtelung Vorkommen
min - max pro Verifizierungsinformations-Block		 Typ / Länge Wertebereich Beschreibung

[VerificationInformation]

<verification:verificationInformation xmlns:verification="http://registry.denic.de/verification/5.0" xsi:type="verification:verificationInformationType">

<verification:verifiedClaims>

<verification:verificationResult>

<verification:verificationReference>

<verification:verificationTimestamp>

<verification:verificationEvidence>

<verification:verificationMethod>

</verification:verificationInformation>

-

-

Einmal pro Verifikationsdatensatz

-

-

Bei K/V: Kopfzeile, die dem Verifikationsdatensatz voran steht

-

-

<verification:verifiedClaims>

<verification:claim>

</verification:verifiedClaims>

-

-

-

-

-
VerifiedClaim -

-

<verification:claim>

...

<verification:claim>

 1 - 3 normalizedString /
feste Länge durch vordefinierte Werte		 claim-rule "claims" sind Daten, die verifiziert wurden.

Besonderheit bei E-Mail
Der komplette Verifizierungsinformations-Block mit allen Schlüsselwörten bzw. XML-Elementen und Werten muss bei einer E-Mail-Prüfung angegeben werden, wenn das Ergebnis der Prüfung negativ war, also den Wert "failed" hat.

Eine nachfolgendes Update mit dem positiven Wert "success" muss ebenfalls mitgeteilt werden.

War bei der Prüfung von Anfang der Wert "success" vorhanden kann der Verifizierungsinformations-Block mitgeteilt werden.
VerificationResult -

<verification:verificationResult>

...

</verification:verificationResult>

-

 1 normalizedString /
feste Länge durch vordefinierte Werte		 result-rule Mitteilung über das Ergebnis der Verifikation
VerificationReference -

<verification:verificationReference>

...

/verification:verificationReference>

-

 1 normalizedString /
Länge wird vom Mitglied festgelegt		 reference-rule Der Inhalt ist ein Freitext für eine Referenz auf eine Auftragsnummer, Bestellnummer, Kundennummer etc.
VerificationTimestamp -

<verification:verificationTimestamp>

...

</verification:verificationTimestamp>

-

 1 date-time timestamp-rule Zeitpunkt, zu dem die Verifikation durchgeführt wurde.
VerificationEvidence -

<verification:verificationEvidence>

...

</verification:verificationEvidence>

-

 1 normalizedString /
feste Länge durch vordefinierte Werte		 evidence-rule Nachweis, der bei der Verifikation geprüft wurde (z.B. für den Wert "idcard", was dem Personalausweis entspricht)
VerificationMethod -

<verification:verificationMethod>

...

</verification:verificationMethod>

-

 1 normalizedString /
feste Länge durch vordefinierte Werte		 method-rule Methode, mit der die Verifikation durchgeführt wurde (z.B. für den Wert "pvr", was der Nachweis über die Methode "Video-Identifikation" wäre
TrustFramework -

<verification:trustFramework>

...

</verification:trustFramework>

-

 1 normalizedString /
feste Länge durch vordefinierte Werte		 framework-rule Framework, das zu Verifikation herangezogen wurde.

Bisher gibt es nur den Wert "de_denic", ggfs. folgen später weitere.

 

Aufbau und Regeln zur Bearbeitungin Aufträgen für den Contact des Typs REQUEST

K/V-Schlüsselwort XML-Namensraum und Element Vorkommen
min - max 		Typ / Länge Wertebereich Beschreibung Policy
Handle contact:handle 1 token 9 - 32 contact-rule Eindeutige ID des Contacts. Syntax: <RegAccId>-<ID vom Mitglied> Das Handle eines Contacts muss immer mit der eigenen RegAccId des verwaltenden RegAccs beginnen.
Type contact:type 1 enumeration role-erule REQUEST = eine E-Mail oder eine URL im URI-Template-Format. Für General Request und Abuse Contact darf Type nur REQUEST sein.
URI-Template contact:uri-template 1 normalizedString
8 - 1024 		Aufbau siehe gemäß RFC 6570 - URI Template Die Variablen "Ulabel" und "Alabel" im URI-Template werden bei Domainabfrage (Web-whois) mit der Domain ersetzt. Der Inhalt des URI-Templates wird bei einem CREATE-Auftrag als Test in eine URL oder E-Mail umgewandelt (Für "Alabel" und "Ulabel" wird eine Beispieldomain verwendet.) um die syntaktische Korrektheit zu überprüfen.